Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/web/src/app/internal/agent-sessions/agent-sessions-content.tsx`:
- Around line 64-66: The current assignment for `log` uses `logsByBranch` as a
fallback even when `s.sessionId` is present, which can attach another session’s
metadata; change the `log` resolution so that when `s.sessionId != null` you
only use `logsById.get(s.sessionId)` (even if undefined) and do not fall back to
`logsByBranch`, and only run the branch-name heuristic
(`logsByBranch.get(s.branch)`) when `s.sessionId` is null; update the `log`
variable assignment in agent-sessions-content (the line that references
`s.sessionId`, `logsById`, and `logsByBranch`) accordingly.

In `@apps/wiki-server/drizzle/0063_add_session_id_to_agent_sessions.sql`:
- Around line 18-20: The migration currently uses `IF NOT EXISTS` which masks
schema drift; update the statements in migration 0063 to remove `IF NOT EXISTS`
so the DDL fails loudly if a stray `session_id` column or `idx_as_session_id`
index already exists. Specifically, change the ALTER TABLE on "agent_sessions"
to add the "session_id" integer REFERENCES "sessions"("id") ON DELETE SET NULL
without `IF NOT EXISTS`, and create "idx_as_session_id" without `IF NOT EXISTS`,
so conflicts surface during migration application and preserve the intended FK
and ON DELETE behavior.

In `@apps/wiki-server/src/schema.ts`:
- Line 765: Change the sessionId column definition to match sessions.id by
replacing integer("session_id") with bigint("session_id", { mode: "number" }) in
the schema (preserve the .references(() => sessions.id, { onDelete: "set null"
}) part); also update the corresponding migration
(0063_add_session_id_to_agent_sessions.sql) to create the session_id column as
BIGINT instead of INTEGER so the FK types align.

In `@crux/wiki-server/sync-session.ts`:
- Around line 132-136: getAgentSessionByBranch() can return a non-unique branch
row and updateAgentSession(...) unconditionally clobbers sessionId; change the
client to skip any agent session rows that already have a sessionId (check
agentSessionResult.data.sessionId) before calling updateAgentSession, only PATCH
when sessionId is null/undefined, and add a TODO comment to implement a
server-side compare-and-set for sessionId to make this atomic later.
- Around line 121-143: Replace the direct createSession(...) call in main() with
a call to syncSessionFile(resolved) so the FK-linking logic in syncSessionFile
is executed; adjust syncSessionFile to return the created session result (or an
object with ok and sessionId) instead of only boolean (so callers can inspect
result.ok and result.sessionId), and update main() to check result.ok and log
the created session id (e.g. "✓ Session synced to wiki-server (id: ...)" ) when
successful; refer to functions syncSessionFile, createSession, and main to
locate the changes.

---

Outside diff comments:
In `@apps/wiki-server/src/routes/agent-sessions.ts`:
- Around line 141-148: The PATCH handler in agent-sessions.ts writes sessionId
directly into agent_sessions (see the sessionId check and the db.update call
using getDrizzleDb() and agentSessions) without ensuring the referenced session
exists, which can cause a DB foreign-key error; fix it by either (A) validating
the sessionId before updating: query the sessions table (sessions) for the given
sessionId and return a 404/400 if not found, then proceed with the update, or
(B) wrap the db.update(...).returning() in a try/catch, detect a foreign-key
constraint violation from the database error and translate it into a
deterministic 4xx response (400 or 404) instead of letting it bubble as a
500—apply the approach that matches the codebase error-handling conventions.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/wiki-server/src/__tests__/agent-sessions.test.ts`:
- Around line 93-95: The mock dispatcher currently assigns any numeric
session_id in the "case \"session_id\"" branch (store[idx].session_id =
params[pIdx]) which allows invalid foreign keys; update this branch to enforce
the FK by either validating the assigned id exists in the test sessions fixture
(e.g., check against the in-memory sessions array used by the tests) and
throw/return the same error path the real schema would (invalid_reference/400)
when missing, or alternatively seed a minimal sessions fixture with the expected
session id(s) and assert existence before assignment; reference the "case
\"session_id\"" switch and the test's sessions fixture/in-memory sessions array
to locate where to add the check.

In `@apps/wiki-server/src/routes/agent-sessions.ts`:
- Around line 145-156: The catch block around the db.update(...).returning()
currently inspects the error message string to detect a foreign key violation;
update it to check the PostgreSQL SQLSTATE code instead by testing the caught
error object (e) for a code property equal to "23503" (e.g., use a type guard
like (e as { code?: string }).code === "23503") and keep the same response for
that case; ensure you still derive msg for other logging/handling but stop using
msg.includes("foreign key") or similar string checks.

In `@crux/pr-patrol/index.ts`:
- Around line 1208-1227: The current resolveBotReviewThreads function
unconditionally attempts to resolve every thread in the provided botComments
list, which can close valid unresolved feedback; change the logic so
resolveBotReviewThreads only processes threads that were explicitly marked as
fixed by the agent or verified by a post-fix checker (e.g., accept and iterate a
filtered list like fixedBotComments or require a flag on each BotComment such as
comment.fixed/ comment.verified), update callers that currently pass
pr.botComments to instead pass only the confirmed-fixed subset, and ensure the
function continues to use comment.threadId when calling githubGraphQL so only
those confirmed threads are resolved.